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(57) Abstract: A method for operating a computer system (100, 200) to provide an optimized memory allocation (102, 121, 122) 
for Java functions (1 12) comprises the steps of (i) reading a Java program (240, 250) with classes and interfaces having functions 
within the classes to establish an interference graph (300) with nodes (301-305) for each interface and inter-node edges (331-335) 
for the occurrence of first and second interfaces within a single class; and (ii) assigning unique offsets (e.g., Offset=Q) to pluralities 
of interfaces (e.g., 1 and 3) which are not connected by said edges; and (iii) storing corresponding pointers (129, e.g., PFT 1, PFT 
3) in the memory (102) in sections (121) for each class wherein each pointer in the plurality is identified by the previously assigned 
offset. 
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METHOD FOR PROVIDING AN OPTIMIZED MEMORY ALLOCATION FOR JAVA FUNCTIONS 



Field of the Invention 

The present invention generally relates to computer systems and methods to operate 
them, and, more particularly, relates to a Java computer system, a storage medium and 
an apparatus to optimize addresses. 

Background of the Invention 

The programming language "Java" found widespread use in software applications 
which control the operation of different hardware (e.g., computer controlled 
household appliances) without the need to be rewritten. In other words, a single Java 
application runs on different target computers (e.g., microprocessors of different 
manufactures). 

However, this feature requires control software which is memory consuming and 
which eventually delays the execution of the application at run-time. It is an object of 
the present invention to provide an improved method to operate a computer which 
mitigates the disadvantages of the prior art. 

Brief Description of the Drawings 

FIG. 1 illustrates a simplified block diagram of computer system in which the present 

invention can be embodied; 
FIG. 2 illustrates a simplified pseudo source code listing for a Java application; 
FIG. 3 illustrates a simplified block diagram with a partial view of a memory having 

runtime structures divided into sections; 
FIG. 4 illustrates a simplified block diagram of a plurality of run-time structures for a 

plurality of classes according to the prior art; 
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FIG. 5 illustrates a simplified block diagram of a plurality of run-time structures for a 

plurality of classes according to the present invention; 
FIG. 6 illustrates a simplified interference graph according to the present invention by 

example; 

FIG. 7 illustrates a simplified interference graph in an inversion of the graph of 
FIG. 6; and 

FIG. 8 illustrates a simplified flow chart diagram of a method in a preferred 
embodiment of the present invention. 

Detailed Description of a Preferred Embodiment 

The present invention is explained in connection with the programming language 
Java, but this is not limiting. Those of skill in the art are able, based on the 
description herein, to apply the present invention to other languages without departing 
from the scope of the present invention. For convenience, a glossary of terms is 
provided prior to the claims. 

FIG. 1 illustrates a simplified block diagram of computer system 10 in which the 
present invention can be embodied. For convenience, system 10 is illustrated by 
target computer 100 and host computer 200 (dashed boxes) having different 
functionality. However, computers 100 and 200 can physically be implemented by 
the same hardware. 

Target computer 100 is a computer on which an application is executed (at 
application run-time). For example, target computer 100 controls the operation of a 
household appliance. As every computer, target computer 100 has target processor 
101 which is controlled by target instructions ("native instructions" or "machine 
instructions") stored in a target memory 102 (coupled by bus 103). Since target 
computer 100 is often a low-price mass product, processor 101 and memory 102 
should be as small as possible. 

Host computer 200 is a computer needed to provide target computer 100 with 
target instructions 1 1 1 (e.g., in section 1 10 of memory 102). Similar as above, host 
computer 200 has host processor 201 coupled to host memory 202 by bus 203. 
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For convenience of explanation, bus 1 1 between busses 103 and 203 couples 
computers 100 and 200. Preferably, this connection is provided only temporarily. to 
transfer data from computer 200 to computer 100 (also vice versa). Persons of skill in 
the art are able to provide data transfer by other means, such as, for example, via 
further memory (hard and floppy disks, CD-ROMs, tapes). 

Java compiler 230 reads application software 240 in its source code 
representation (e.g., files with extension "Java"). Java compiler 230 preferably does 
not consider the type of the target processor. Java compiler 230 usually operates on 
host computer 200 (e.g., in memory 202), but this is not essential. Java compiler 230 
- optionally - provides intermediate representation 250 of application software 240 in 
a so-called bytecode representation (e.g., files with extension ".class"). Preferably, the 
bytecode is a sequence of intermediate instructions each having an opcode (one byte, 
e.g., "add") and having zero or more operands (e.g., variables). 

Native compiler 260 reads software in its bytecode representation 250 and 
provides target instructions 111. Native compiler 260 operates on host computer 200 
(as illustrated) or on target computer 100. Java compiler 230 and native compiler 260 
can be combined into a single compiler. Native compiler 260 has to be implemented 
for each available target processor 101. 

Native compilers are classified (a) in static compilers or (b) Just-In-Time (JIT) 
compilers. The present invention will be explained by example for compiler 260 
being a static compiler. Persons of skill in the are able, based on the description 
herein, to apply the present invention also for other types. 

JIT compilers can be considered as dynamic compilers because they operate in 
close cooperation with (c) Virtual Machines (VM). The classification depends on the 
computer where the native compiler operates (host 200 or target 100), the operation 
time (before or during application runtime), and on other criteria. 

(a) The static compiler (e.g., compiler 260) operates on host computer 200 and 
provides target instructions 1 10 which are communicated to target memory 103 by so- 
called executable files (e.g., through bus 1 1). Static compiler 260 operates before 
application run-time. 

(b) The JIT compiler operates on target computer 100 at application run-time and 
translates bytecode instructions (e.g., also stored in target memory) into target 
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instructions 111. The JIT also provides predefined instructions sequences (functions) 
to the target memory at application run-time. 

(c) The VM operates on target computer 100 like an interpreter and provides 
target instructions 1 1 1 by decoding bytecode instructions into target instructions at 
application run-time. 

Functions 1 12 are pluralities of predefined instruction sequences (of different 
lengths) stored in target memory 102. As illustrated in FIG. 1, functions 112 have the 
form of target instructions 111. It is also possible to define functions in the bytecode 
instructions (not illustrated). 

Section 120 in memory 102 stores so-called run-time structures RTS(c) 
(reference number 121) for a total number of C classes (having index c). Each RTS(c) 
has (one or more) pointers 122 to functions 1 12 in section 1 10. Preferably, each 
RTS(c) has only pointers to instructions belonging to a single class. 

The present invention provides a method to operate a computer (i.e., host 
computer 200) to provide RTS(c) in such an optimization that the access to target 
instructions 1 1 1 by target processor 101 is faster and less memory consuming than 
with prior art structures. For convenience, it can be assumed that a static compiler 
(e.g., compiler 260 in FIG. 1) receives application 240 (e.g., in source code of FIG. 2) 
and provides target instructions 1 1 1 to memory portion 1 10 in FIG. L 

FIG. 2 illustrates a simplified pseudo source code listing for a Java application 
(e.g., application 240) by way of example FIG. 2 identifies: 

• functions by the word "function" and indices T (interface index) and T 1 (function 
index); 

• interfaces by the word "interface" and index "i"; and 

• classes by the word "class" and index M c". The example of FIG. 2 uses a total 
number of I = 5 interfaces, a total number of C = 6 classes and assumes that each 
interface implementation only has F = 2 functions (index f = 1 , 2). The keyword 
"implements" indicates that a class uses functions of a single interface (e.g., classes 1, 
3 and 6) or of multiple interfaces (e.g., classes 2, 3, and 5). 

In source code using proper syntax, functions are often represented by identifiers 
which are independent from a class (see below). For example, the function 
"X.println( )" sends the value of an object "X" to a printer (e.g. via bus 1 1). The 
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corresponding bytecode instruction is "invokeinterface println" with paramenter "X" 
on an execution stack. In target memory 102, functions are implemented by target 
instructions 1 1 1 forming functions 1 12 (cf. FIG. 1). The literature relating to Java 
describes functions by the term "method". 

Interfaces are pluralities of functions (e.g., F = 2 functions for each interface). 
For example, an output interface comprises functions (e.g., print to printer, write to 
display) which send data from target computer 100 to a peripheral device (e.g., the 
printer or the display). Interface implementations are pluralities of function 
implementations. 

Classes define properties of data and functions. For example, a first class (e.g., 
index c = 1) defines integer variables (i.e., 0, 1, 2, 3...) and a second class (e.g., index 
c = 2) defines characters (i.e., "a ", H b ", "c ",...). 

A function can be defined for a single class or for multiple classes. When a 
function is defined for multiple classes, then target instructions 111 are different for 
each class. Assume, for example, that the function n X.println( )" is defined both for 
the class 1 (integer) and for the class 2 (characters). Target instructions 111 for 
printing integer variables and for printing characters are different (i.e., different 
pointers 122 from different RTS). In other words, the function has a first 
implementation (target instructions for the first class) and has a second 
implementation (target instructions for the second class). Depending to which class 
an object "X" belongs to, the target processor uses different target instructions 
(hereinafter "function implementations") for the same function (as mentioned above 
having class-independent identifier). 

For example, the target processor executes the above mentioned function 
"X.println( )" with first target instructions when variable X stores an object of the 
integer class or with second, different target instructions when X stores an object of 
the character class. Java allows to define a variable X as a variable of the integer class 
or of the character class if both classes support an output interface. An object 
indicates an actual value stored, for example, in a variable. 

It is an advantage that target processor 101 accessing memory structure 120 of the 
present invention loads suitable target instructions 1 1 1 faster than a target processor 
accessing prior art structures. 
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The number of interfaces implemented by a given class is referred to as Iclass(c) 
with, for example (FIG. 2): 

ICLASSO) = ICLASS(3) = IcLASs(6) =1, (1) 

Iclass(3) = Iclass(5) = 2 and 

5 Iclass(2) =3. 

A class using two or more interfaces is referred to by the term "multiple interface 
class", abbreviated "MIC". The example of FIG. 2 illustrates a total number of J = 3 
MIC 2, 3 and 5. 

FIG. 3 illustrates a simplified block diagram with a partial view of memory 102 
10 having RTS(c) (a single class c) divided into section 125 and section 126. Section 

125 is further divided into S slots 127. Section 126 is further divided into further slots 
128 for function tables. Slot 127 comprises pointer 129 to the function tables 
(hereinafter "pointer to function table - PFT") stored in slots 128. One PFT only 
points to the function tables for a single interface. In the following, two or more PFTs 
15 are distinguished by interface index i. 

Slot 127 can be empty, but this should be avoided. The function tables have 
pointers 122 to target instructions 1 1 1 (cf. FIG. 1). Although convenient, splitting the 
RTS(c) into function tables is not essential for the present invention. Therefore, 
RTS(c) is further discussed or illustrated only in connection with the PFT in slots 127. 
20 Each slot is identified by an offset counter "Offset" preferably having values between 
Offset = 0...S-1 (2) 
In other words, Offset is the address by which the PFT is identified. According to the 
present invention, the number S of slots (e.g., S = 3) is smaller than the total number I 
of interfaces (e.g., I = 5). This is a major advantage over the prior art. The following 
25 FIGS, illustrate how this can be achieved. 

FIG. 4 illustrates a simplified block diagram of a plurality of run-time structures 
(RTS(l) to RTS(6) for classes 1 to 6, "CI " to "C6") according to the prior art. For 
convenience, RTS(l) to RTS(6) are illustrated next to each other so that slots 127 
having equal Offset (0...4) are adjacently placed. Each RTS(c) has S = I slots, 
30 resulting in a total number of S * C = I * C slots (e.g., 5*6 = 30). 

The first slot row (Offset = 0) stores only PFTs for interface 1 ("PFT 1 "), the 
second slot row (Offset = 1) stores only PFTs for interface 2 and so on. Or, looking at 
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columns, RTS(l) for class 1 only stores the PFT for interface 1 (cf. statement (21) in 
FIG. 2), RTS(2) for class 2 only stores the PFTs for interfaces 1, 2, and 4 (cf. (22) in 
FIG. 2) and so on. From the total number of 30 slots, 10 slots are used to store PFTs 
and 20 slots are empty, resulting in a used-to-total ratio 10 to 30, or 33%. 
5 FIG. 5 illustrates a simplified block diagram of a plurality of run-time structures 

(RTS(l) to RTS(6) for classes 1 to 6, "CI" to "C6") according to the present 
invention. Similar as in FIG. 4, RTS(l) to RTS(6) are illustrated next to each other so 
that slots 127 having equal Offset (values 0...2) are adjacently placed. Persons of skill 
in the art can place RTS(c) otherwise, for example, arbitrarily in a heap. Each RTS(c) 
10 has only S'< I slots, resulting in a total number of S' * C slots (e.g., 3*6=18). From 
the total number of 18 slots, 10 slots are used to store PFTs and only 8 slots are 
empty, resulting in an higher used-to-total ratio 10 to 18, or 55%. 

Different to the prior art, the first slot row {Offset = 0) stores the PFT for interface 
1 and for interface 3, the second slot line {Offset = 1) stores the PFTs for interface 2 
15 and 5; and the last row stores the PFTs for interface 4. Looking at the columns, 
RTS(c) store the tables as above. 

It will now be explained how PFT offsets are assigned to the interfaces. 

(i) According to a first assignment rule of the present invention, sets of interfaces 
which do not belong to common classes (i.e. equal index c) have the same offset. For 

20 example, a first set comprises interfaces 1 and 3 which belong to different classes (cf. 
FIG. 2, interface 1 to classes 1, 2 and 5 and interface to classes 3 and 4). The first set 
has been assigned to Offset = 0. A second set comprises interfaces 2 and 5 which also 
belong to different classes (cf. interface 2 to classes 2 and 3 and interface 5 to class 5). 
The second set has been assigned to Offset = 1. Finally, a third set with the single 

25 interface 4 has been assigned to Offset = 2. Among other combinations, it is also 
possible, for example, to assign Offset = 1 to the first set (interfaces 1 and 3) and to 
assign Offset = 0 the second set (interface 2 and 5). 

(ii) According to a second assignment rule, applied optionally, the smallest offset 
( e -g-> Offset = 0) is assigned to that interface set (e.g., interfaces 1 and 3) implemented 

30 by most of the classes (e.g., by 5 classes 1-5 out of C = 6). 

(iii) According to a third assignment rule, also applied optionally, the smallest 
offset (e.g., Offset = 0) can be assigned to that interface set (e.g., interfaces 1 and 3) 
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which comprises the highest number of interfaces in a set (in the example, sets with 2 
interfaces). 

It is convenient for explanation to discuss the offset assignment with the help of a 
graphical representation. 

FIG. 6 illustrates simplified interference graph 300 according to the present 
invention by example (cf. FIG. 2). Graph 300 has nodes 301 to 305 corresponding to 
interfaces 1 to 5, respectively, and has edges 33 1-335 between some pairs of nodes. It 
is understood that graph 300 is a mere representation for the convenience of 
explaining an analysis according to the present invention. Persons of skill in the art 
can perform such an analysis by a computer (e.g., host computer 200) without 
displaying a graph. 

Edge 33 1 at node pair 301/302 represents the occurrence of interfaces 1 and 2 in 
statement (22); edge 332 at node pair 302/304 represents interfaces 2 and 4 in the 
same statement (22); edge 333 at node pair 301/304 represents interfaces 1 and 4 in 
the same statement (22); edge 334 of node pair 302/303 represents interfaces 2 and 3 
in statement (23); and edge 335 of node pair 301/305 represents interfaces 1 and 5 in 
statement (25). 

FIG. 7 illustrates simplified interference graph 300' in an inversion of graph 300. 
Similar as above, graph 300' has nodes 30 T to 305' corresponding to interfaces 1 to 5, 
respectively. Graph 300' has edges 320, 321, 322 and 323 between pairs of nodes 
where graph 300 of FIG. 6 does not have edges. Edge 320 (nodes 30 T, 303*) indicates 
that interfaces 1 and 3 are independent so that they can be assigned a common offset 
(e.g., Offset = 0). Edge 321 (nodes 302*, 3050 indicates that interfaces 2 and 5 are 
independent so that they also can be assigned a further common offset (e.g., Offset 
= 1). Edges 323 and 322 indicate the independence of interface 4 to interfaces 3 and 
5. 

The problem of assigning offsets can be considered as a graph-coloring problem 
when different offsets are considered as different colors of the nodes of graph 300. 
Such problems can be solved by procedures well known in the art. The solution 
proposed in connection with FIG. 8 is intended to illustrate a preferred embodiment of 
the present invention. However, persons of skill in the are able to solve the graph- 
coloring problem by other means. 
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The present invention is now described as a method for providing a run-time 
structure (e.g., RTS(c)) for an application (e.g., Java) to a memory (e.g., memory 102 
of target processor 100). The steps are (i) reading a code representation (e.g., source 
code 240, byte code 250) of the application in which interfaces are used by classes (cf. 
FIG. 2, "class ... implements interface ..."); and (ii) writing, separate for each class, 
PFTs to memory locations (e.g., slots 127) which are identified by interface offsets 
(e.g., Offset) within the classes (e.g., within RTS(c) for class c). The method 
characterized in that • reading comprises identifying at least a first set of first and 
second interfaces (e.g., interfaces 1 and 3) such as there is no class which uses 
together first and second interfaces of the first set (e.g., classes 1 to 6 do not use 
interfaces 1 and 3 together), and • writing comprises assigning a first common offset 
(e.g., Offset = 0) to corresponding first and second PFTs (e.g., PFT 1, PFT 3 in 
FIG. 5) which belong to the first and second interfaces, respectively, of the first set. 

By repeating reading and writing for a second set of further interfaces (e.g., 
interfaces 2 and 5) with a second common offset (e.g., Offset = 1) the method, 
preferably, assigns the smallest offset (e.g., first common offset) to that set (set with 
interfaces 1 and 3) which is used by most of the classes (e.g., by 5 classes 1 to 5). 

In other words, the present invention describes a method for operating a computer 
system (e.g., system 10 with computers 100 and 200) to provide an optimized memory 
allocation (e.g., target memory 102, run-time structure 121, pointer 122) for Java 
functions (112) which comprises the steps of (i) reading a Java program (240, 250) 
with classes and interfaces having functions within the classes (cf. FIG. 2) to establish 
an interference graph (300) with nodes (301-305) for each interface and inter-node 
edges (331-335) for the occurrence of first and second interfaces within a single class; 
and (ii) assigning unique offsets (e.g., Offset = 0) to pluralities of interfaces (e.g., 1 
and 3) which are not connected by the edges; and (iii) storing corresponding PFTs 
(e.g., PFT 1, PFT 3) in the memory (e.g., memory 102) in sections (e.g., RTS 121) for 
each class wherein each PFT (i.e., PFT 1 and PFT 3) in the plurality is identified by 
the previously assigned offset. 

FIG. 8 illustrates a simplified flow chart diagram of method 400 in a preferred 
embodiment of the present invention. For convenience of explanation, it is assumed 
that the steps are performed by host computer 200 being controlled by compiler 260. 



10 



Persons of skill in the art can, based on the description herein, perform method 400 by 
other means without departing from the scope of the present invention. According to 
method 400, computer 200 analyzes the source code for the occurrence of interfaces, 
identifies interface sets, and assigns offsets to the interface sets. Method 400 
comprises the following steps: start 401, numbering classes 410, bit vector defining 
step 420, 425, interference checking step 430 (query with YES 43 1, NO 432), offset 
assigning step 440, merging step 450, 460, and end 499. Steps 425 and 430 in 
combination form identifying interface sets step 435 (dashed frame). 

Preferably, computer 200 executes method 400 in the following order: start 401, 
numbering classes 410; bit vector defining 420 and 425; interference checking 430, 
NO 432, offset assigning 440, merging 450 (or, optionally 450 first, 440 second), and 
in a repetition (line 455) again bit vector defining 425. If during checking 430, 
interference is detected, YES 43 1, assigning 460 and end 499 follow. Method 400 
continues as long as there are interfaces available to perform bit vector defining step 
425, or otherwise terminates (not illustrated for convenience). 

In numbering classes step 410, computer 200 determines from the source code 
which classes use only a single interface (e.g., classes 1 and 4) and which classes use 
two or more interfaces (multiple interfaces classes, MICs, cf. above introduced 
equations (1)) and assigns indices j=0 to J-l to the MICs. The following indices are 
used in the example: 

class 2 -> MIC 0 j = 0 (3) 

class 3 -> MIC 1 j = 1 

class 5 ->MIC2 j = M = 2 

In bit vector defining step 420, 425, computer 200 provides a bit vector B(i) 
having J bits b(i, j) for interface i according to: 

B(i) = {b(i,0),...b(ij), ... b(i,J)} (4) 

b( i, j ) = 1 if MIC j implements interface i 

= 0 otherwise 

Computer 200 can obtain the bit vectors from the source code. The bit vectors (bit 
triples, J = 3) for the example of FIG. 2 are: 
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B(l) = { 1, 0, 1 } (for interface 1) (5) 

B(2) = { 1, 1, 0 } (for interface 2) 

B(3) = { 0, 1, 0 } (for interface 3) 

B(4) = { 1 , 0, 0 } (for interface 4) 

5 B(5) = { 0, 0, 1 } (for interface 5) 

In B(l), the first bit is "1" because MIC 0 (class 2, cf. statement (22) in FIG. 2) uses 
interface id; the second bit is "0" because MIC 1 (class 3, cf. statement (23)) does 
not use interface i = 1; and the third bit is "1 " because MIC 2 (class 5, cf. statement 
(25)) uses interface i = 1. In FIG. 8, reference number 420 is used for an initial bit 
10 vector defining (e.g., of B(I)), and number 425 is used for defining second and further 
bit vectors (e.g., B(2), B(3)). It is understood, that once a bit vector has been defined, 
the bit vector is conveniently stored in memory (e.g., memory 202) so that a 
recalculation is not required. 

In interference checking step 430, computer 200 compares at least two bit vectors 
1 5 B(i) and B(iO and provides check vector Check (i, V) by applying logical and- 
operations to corresponding bits b with equal j-index, that is: 

Check (i, V) = B(i)«mfB(i) (6) 
Check{\,Y)={ [b(i,0)a/u/b(i',0)], 

20 [b(i,j)a«rfb(i',j)], 

[b(i,J)anrfb(i\J)] } 
In the example, the anJ-operation provides for B(l) and B(2): 

Check (1,2) = { [ 1 and 1 ] [ Oand 1 ] [ 1 and 0 ] } (7) 

25 ={1,0,0} 

By checking, computer 200 answers the questions "Interference possible?". For at 
least a single occurrence of a "1" in Check (i, i), there would be a possible 
interference (line YES 431). When all elements of Check (i, I 7 ) are "0", there would 
be no interference (line NO 432), that is, for example, 
30 Check (1,3) ={ [\ andO][Q and \] [ landO] } (8) 

={000} 
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Although explained here for only two bit vectors, it is understood that checking 430 
can be applied for any number of bit vectors and that checking 430 (and step 425) can 
be repeated until no more bit vectors defined in the previous step 425 remain. For 
simplicity, FIG. 8 does not illustrate repetitions of step 430. As mentioned above, 
5 interference checking step 430 and bit vector defining step 425 form interface set 

identifying step 435 provide the set of non-interfering interfaces. In other words, each 

time method 400 reaches line 432, computer 200 has identified a new interface set. 

Persons of skill in the art can arrange this without the need of further explanation 

herein. 

10 In offset assigning step 440, 460 computer 200 assigned an equal offset to all 

interfaces of a set or to a single interface, as for example: 

Offset : = 0 for interfaces 1 and 3 (9) 

Assigning can be preliminary so that, optionally, consecutive performed assigning 

steps overcome the old assignment. In FIG. 8, reference number 440 is used for the 
15 assigning step which follows the detection of interface sets; and number 460 is used 

for the assigning step for an offset of the last remaining interface. The repetition of 

step 440 comprises that the value for Offset is incremented for each assignment. 

Persons of skill in the art can take the necessary measures without the need of further 

explanation herein. 

20 In merging step 450, computer 200 combines all bits b(i, j) and b(i', j) of first bit 

vectors B(i) and second bit vector B( i) by logical or-operations and provides a new 
bit vector B°(i) which is identified by the index "i" (same as the first bit vector) and 
the superscript circle ° symbol. Preferably, the first bit vector B(i) is no longer used 
so that, preferably, B°(i) overrides B(i). However, this is not essential. If merging is 
25 applied to a bit vector B°(i) with one circle °, then the new bit vector is identified by a 
further circle B°°(i) and so forth. The or-operation is applied bitwise, that is: 
B°(i) = B(i)orB(i') (30) 
{ (b(i,0)<>rb(i\0)], 
[b(i,j) orb(i'J)], 

30 

[b(i, J) or b(i',J)] } 
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In the example: 

B°(l) = B(l)orB(3) ( 31 ) 
= { [1 orO] [Oor 1 ] [ 1 orO] } 

= (HI) 

Similar as the above checking step, merging step 450 can be applied to any number of 
bit vectors. In this case, the results of multiple or-operations are accumulated. 
Preferably, merging is applied to the vectors of that interfaces which are identified in 
step 435. 

Referring to the example of FIG. 2, method (400) can be performed as follows: 
numbering 410; defining B(l) using source code 420; defining B(2) using source code 
425; checking 430 B(l), B(2), "Interference?" YES, in repetition defining 425 B(3) 
using source code checking 430 B(l), B(3), Check (1,3)= { 000}, "Interference?" 
NO; assigning Offset = 0 to the interface set of interfaces 1 and 3; merging 450 B(l), 
B(3) to B°(l) (becoming an "no interference bit vector" for interfaces 1 and 3); 
continuing at steps 425 and 430 wherein B°(l) is checked with B(4) and so on. 

Further, method 400 of the present invention can also be explained as follows. 
By executing numbering step 410 and defining step 420 for all B(l) to B(5), computer 
200 stores bit matrix { B } having bit vector B(i) represented in columns. Matrix 
{ B } has J rows (e.g., 3) and comprises bits b(i, j) as described above. The following 
representation by columns and row is convenient, but not essential, those of skill in 
the art can transform the matrix by replacing columns and rows. 

B(l) B(2) B(3) B(4) B(5) (32) 

110 10 
{ B } = 0 1 1 0 0 

10 0 0 1 
Computer 200 now swaps column B(3) and B(2), thus storing a modifying the matrix, 
that is 

B(l) B(3) B(2) B(4) B(5) (33) 
10 110 
{B}#= 0 1 1 0 0 
10 0 0 1 
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The # symbols stands for the modification. By applying checking step 430, computer 
200 now obtains submatrix B(l) B(3) for which Check (1, 3) = { 0 0 0 }. By further 
swapping columns and checking steps, the matrix has been ordered to 

B(l) B(3) B(2) B(5) B(4) (34) 
10 10 1 
{ B }##= 0 110 0 
1 0 0 1 0 
{ B } ## comprises submatrices B(l) B(3) and B(2) B(5) standing for interface sets 
each comprising non-interfering interfaces. In other words, by swapping, computer 
200 identifies interface sets (cf. step 435). By assigning step 440, PFT offsets are for 
each submatrix, that is Offset =0 for submatrix B(l) B(3), Offset = 1 for submatrix 
B(2) B(5), and Offset = 2 for submatrix B(4). 

The present invention can also be described as an apparatus (e.g., host computer 
100) to provide addresses (Offset, c) for PFTs in run-time structures (e.g., memory 
section 120) pointing (e.g., pointer 122) to target computer instructions (e.g., 
instructions 111), the apparatus receiving code (e.g., source code 240 in Java with an 
application) indicating which program segments (e.g., classes) implement which 
interface (i.e., set of functions) and providing addresses each having a first portion 
(e.g., index "c" for class) corresponding to the program segment and a second portion 
(e.g., Offset) which is equal to all interfaces of the same type throughout the segments, 
the apparatus characterized in that the apparatus provides addresses with equal second 
portions also for interfaces of different types which are implemented by the classes in 
a non-overlapping assignment. 

The present invention can also be described as a storage medium (102) for storing 
Java run-time structures (120) with memory locations (127) storing pointers (PFT, 
129), wherein (a) the pointer point to functions (112) belonging to interfaces, (b) some 
of the interfaces are implemented by classes, and (c) the memory locations are 
identified by a first index representing the class and a second index representing an 
offset (Offset) within a set (RTS(c)) of memory locations for each class. The storage 
medium (102) id characterized in that some of the memory locations for different 
interfaces (e.g., interfaces 1 and 3) share common second indices (e.g., Offset = 0) 
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when the functions (1 12) pointed to by the pointers (129) in the memory locations are 
not commonly implemented by two classes. 

While the invention has been described in terms of particular structures, devices 
and methods, those of skill in the art will understand based on the description herein 
that it is not limited merely to such examples and that the full scope of the invention is 
properly determined by the claims that follow. 
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Glossary of terms 

In the following, abbreviations, and writing conventions are listed alphabetically. 
This glossary is provided only for convenience. 

5 

b(i,j) bit 

B(i) bit vector 

B°(i) new bit vector 

{ B } matrix 

1 0 Check (i, i') check vector 

f index for functions 

F number of functions, e.g., F = 2 for all interfaces i 

i index for interfaces 

I number of interfaces, e.g., I = 5 

15 c index for classes 

C number of classes, e.g., C = 6 

Iclass(c) number of implemented interfaces in a class 

j index for multiple interface classes (MCI) 

J number of MIC 

20 MIC multiple interface class 

Offset offset to identify PFTs in the run-time structure 

PFT pointer to function table 

S, S' number of slots 

X variable 
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Claims 

1. A method for providing a run-time structure for an application to a computer 
memory, the method comprising the steps of: 

reading a code representation of said application in which interfaces are used by 
classes, thereby identifying at least a first set of first and second interfaces such 
as there is no class which uses together said first and second interfaces of said 
first set; and 

writing, separate for each class, pointer to function tables (PFT) to memory 
locations which are identified by offsets within the classes, thereby assigning a 
first common offset to corresponding first and second PFTs which belong to 
said first and second interface, respectively, of said first set. 

2. The method of claim 1 characterized by repeating reading and writing for a second 
set of interfaces with a second common offset so that the smallest offset is assigned 
to that set which is used by most of the classes. 

3. The method of claim 1 wherein identifying comprises determining first elements 
corresponding to the interfaces regardless to classes, associating some of said first 
elements by second elements to indicate the use of said first and second interfaces 
by said first class, and obtaining the first set from these first elements which are not 
associated by said second elements. 

4. The method of claim 3 wherein said first elements are nodes of an interference 
graph and said second elements are edges between nodes of said graph. 

5. The method of claim 1 wherein identifying comprises solving a graph coloring 
problem. 

6. The method of claim 1 wherein said offsets are integer numbers. 
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7. The method of claim 1 wherein further sets are identified and further offsets are 
assigned and the smallest offset is assigned to that set which has most interfaces. 

8. The method of claim 1 applied to Java applications. 

9. The method of claim 1 wherein identifying comprises to define bit vectors for 

interfaces which indicate interface occurrence in multiple interface classes, and to 
compare bit vectors at least two interfaces by logical operations. 

10. A method for operating .a computer system to provide an optimized memory 
allocation for Java functions, the method comprising the steps of: 

reading a Java program with classes and interfaces having functions within the 
classes to establish an interference graph with nodes for each interface and inter- 
node edges for the occurrence of first and second interfaces within a single 
class; 

assigning unique offsets to pluralities of interfaces which are not connected by said 
edges; and 

storing pointers to function tables in the memory in sections for each class wherein 
each pointer in the plurality is identified by the previously assigned offset. 

1 1. The method of claim 10 wherein the assigning step comprises solving a graph- 
coloring problem. 

12. The method of claim 10 wherein said native instructions are identified via 
function tables. 
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13. An apparatus to provide addresses for pointers in run-time structures pointing to 
target computer instructions, said apparatus receiving an assignment code 
indicating which program segments implement which interface and providing 
addresses each having a first portion corresponding to the program segment and a 
second portion which is equal to all interfaces of the same type throughout the 
segments, said apparatus characterized in that said apparatus provides addresses 
with equal second portions also for interfaces of different types which are 
implemented by the classes in a non-overlapping assignment. 

14. A storage medium for storing Java run-time structures with memory locations 
storing pointers, wherein the pointer point to functions belonging to interfaces, 
some of the interfaces are implemented by classes, and the memory locations are 
identified by a first index representing the class and a second index representing an 
offset within a set of memory locations for each class, the storage medium 
characterized in that some of the memory locations for different interfaces share 
common second indices when the functions pointed to by the pointers in the 
memory locations are not commonly implemented by two classes. 
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